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(54) Integrated circuit card, secure application module, system comprising a secure application 
module and a terminal and a method for controlling service actions to be carried out by the 
secure application module on the integrated circuit card 



(57) An integrated circuit card (=ICC) with file ori- 
ented memory structure, a secure application module 
(=SAM) with file oriented memory structure, a system 
comprising a SAM and a terminal and a method for con- 
trolling service actions in a multiple service application 
mechanism to be carried out by the terminal on the ICC 
including the following steps: 

a. establishing whether said terminal is allowed to 



carry out said service action on said integrated 
service card by using at least one key stored both 
on said ICC and on said SAM and by checking on 
said SAM predetermined access rights stored on 
said SAM, and 

b. carrying out said service action on said inte- 
grated service card. 
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Descripti n 

Background nf the Invention ' : ' 

The present invention relates to an integrated cir- 
cuit card provided with memory means storing service 
data relating* to 'at least brie service. 

Such integrated circuit cards are now widely used. 
The present invention is intended to be used in multiple 
application r kuthdrizatiori mechanisms. Examples of 
multiple * application authorization mechanisms have 
been Scribed before in, e.g/.US-A5*73,69b: WO-A- 
92/06451, EP-A-0.640,945, EP-A^0,644^13i, WO-A- 
87/07060, EP-A-0,262,025 and EP-A-6,66i;675. 

These' known multiple application authorization 
mechanisms share a direct memory access structure in 
which no directories and files are used. A common fea- 
ture of the known mechanisms is to use a secret codeto 
check whether a secure application module is allowed 
to access an application, indicated by a unique identi- 
fier, oh the ; integrated circurt card. Whenever a secure 
application module w access to this application 
this secret code needs to be reproduced. 

Since these known mechanisms do not use directo- 
ries or file structures the presence of access tables on 
the integrated circuit cards is required. These access 
tabled comprise several entries constituted of the secret 
cod§ for a predetermined application, the related mem- - 
ory locations on the integrated circuit card used for this 
application and the related access rights associated 
with this applicatiori like read/write rights, PIN, etc. 
Mostly, alecret key is required to avoid disclosure of the 
secret code. ' [ \ 

A disaoS^ntage of the known mechanisms referred 
to above is that the access tables on the integrated cir- 
cuit card occupy memory locations. Since nowadays an 
integrated circuit card only has about 8 kilobits memory 
space available this is a serious disadvantage. * 

Rumrharv of thW invention - 



' The object of the present invention is to provide an 
integrated circuit card having its memory organized in a 
directory and file structure l arxiih which memory space 
is saved by reducing the overhead data on the inte- 
grated circuit card per application. ' 

To obtain this object the present invention provides 
an integrated circuit card as defined in the preamble of 
claim t which is characterized in that at least part of the 
memory means comprises service data in file structures 
within one directory comprising a first file and a second 
file, service data being grouped together in service 
slots, any service slot being divided into a profile part 
and a data part, any profile part having a slot-number 
and being stored in the first file and comprising a unique 
ap&ic^biyider^^ being stored in 

the se^phd file aril cor^risirigd^ 
ice, Wmembry'meWfe Coring at least one key to pro- 



tect write access to thetfirst and second files. ■-} 

By meansi of a memory on the integrated circuit 
card structured as defined above it is enough to store 
only One or two keys on the card which are common to 
5 several service applications, Thus, less overhead date 
relating to any of the service applications on the card is 
required and more service applications can be sup- 
ported by the integrated circuit card: ( \ : i- - v, , v ; 
In one embodiment, at least one profile part also 
w comprises data relating to an expiry date of the;seryice 
slot concerned; Such data relating, to an expiry date 
may ; be checked by the secure application -module 
which is communicating with the integrated circuit card. 
If it is established that the date has already expired the 
15 service slot; concerned is^avaiiable to any other new 
service^ application. Thus, no complicated arrange- 
ments tiaVe to> be provided :fbr between the hardware 
provider, the provider of the software and the party who 
is providing the service to the user of the integrated cir- 
20 cuit card. The availability of a service slot of which the 
expiry date has expired can be checked automatically. 

When there ! are 7 different application providers of, - 
the software related to'several services the service slots ; ; 
are preferably structured such that they comprise their 
25 own profile part and their own data part, the prof fle parts 
being implemented as records of ; the first file and the - 
data parts being implemented as records: of the second 
file, the memory means storing a further key to.protect 
access to the first file. In such a case these service slots- 
30 may be called "generic service slots", w . n ^ " 
However, when there is only one application pro- 
vider of the software for several services, preferably the 
implemented service slots share one common; prof He 
part but any service slot comprises its own data part, 
35 - the common profile part being implemented as one 
record of the first file and the data parts being imple- ;■- 
merited as*separate records of the second file. These 
service slots may be called "dedicated service slots". In 
such a case, the first file only comprises one record, 
40 thus saving required niemory space for the profile part 

data. - - ' ' ■ * : ' ' • ' ■ -'" ' 

The directory of the integrated circuit card may be 
extended by a third ffle such that at least one service 
slot comprises an additional data part in the third f Hector 
45 storing additional data. Some service applications need 
a lot of additional data which may be stored in such an 
additional data part. • * ^ ^ 

The present invention also relates to a secure applh 
cation module equipped to communicate with an inte- 
so grated circuit card according to any of the claims ,1> 
through 7, provided with memory means storing service 
data relating to at least one service, characterised in 
that at least part of the memory means comprises serv- 
ice data in f il structures within one directory, the direc- 
55 - tory comprising at least one iile, the at least one file, 
storing ^service data relating to lone r single service, 
- grouped togeth¥r-into: 1 /; - ' ; 
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application/service definitiohr.data comprising a 
unique service identifier^and data indicating a serv- 
ice type; . . ' - 
at least two application counters for administrating 
the number of allocations' and for generating a 
unique record transaction number;* " - 
a service sequence counter for generating a unique 
object number and administrating the number of 
cr&ated'service objects; '* v ■ ;„ 
a service float for administrating the number of 
either issued or received value units and >.r - 
- data "relating to access rights defining., service, 
actions allowed to be performed by.predef ined ter : 
minals, .* « ... 

i and in that the memory means compriseSjat 
least a first key and a second key for protecting any- 
data-communication with an integrated circuit-card; , 

The service definition data and the keys-on the 
secure application module^are used for , the manage- 
ment of the service application, which was controlled by,, 
access tables on the integrated circuit card.in^he.mech- 
anisms' according* tothe prior art. Thus, : management * 
control data is now stored on 4he secure application 
module. instead of on the integrated circuit card ^How- 
ever; this is no serious disadvantage since the available , 
mehlory space on the.secure application module; is less 
critical than f on the integrated circuit card itself.^Moreo- 
ver; such a construction has several advantages. . < r ^ 

First of all, the management of the applications may 
be realized more easily ;since the issuer* of the^inte- 
g rated circuit cards is always able to establish ^direct 
link between the secure application module areJ a cen- 
tral data collect system, which is more difficult between 
the integrated circuit cards and the central data collect, 
system: ^ . v. — . « ;y. 

Secondly, different service acceptants, i,e. parties 
which establish direct links between^irtegrated drcuit 
cards and the secure application module to facilitate a 
service, may be authorized to different access rights. 
The secure application module can easily check which 
service actions are allowed to a service acceptant to be 
carried out on an integrated circuit card; eg. adding loy: 
arty points, subtracting loyalty points, or only displaying 
a total number of loyalty points present on the integrated 
circuit card. - ■■ ■* *, 

By using records within the file structure of the serv- 
ice slot mechanism, the. use of access tables orv the 
integrated circuit cards is avoided. The secure applica- 
tion modulerwill always onjy allow used a specified 
record number, that has been read in a secured way., ; . 

: The present invention also relates to a systemccpm- 
prising a secure application module according to. the, 
invention and at least one 1 terminal coupled to^-the 
secure application module, the terminal being -equipped 
to communicate with the secure application rrodule and 
with at least one integrated circuit according : to - the 
invention in order to control a service carried but on the 
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at least one integrated circuit card. 

Moreover, the present invention relates to a method 
for controlling a service action to be carried out by a ter- 
minal on an integrated circuit card according to any of 
the claims 1 through 7,, the terminal being. coupled to 
both, a secure, application module according .to any of 
the claims 8 or 9 and to the integrated circuit card, ? 
including the following steps: . . 

a. establishing whether the terminal is allowed, to . \ t 
carry out the service action on the irtegrated serv-,. 
ice card by using at least one codeand at least one . ' 
secret key, both the at least one code > and the. at - 
least qne;key being stored on both the integrated* 
circuit card and the secure, application module and 

by checking predetermined access rights, and . 

b. . carrying out the service, action on thejntegrated / 
service card; t ,^ . . ( ( .- , s 

c. checking step p. on the terminal . V \ ... . ^ \ . 
characterised "in that : . " ( , r ^ \;r-- ^ 

v the checking predetermined access;, rights ip ; _ . . J 
. step a is carried out on the secure application mqd- ] / 
ule using the data relating to access, rights stored V. 
on the secure application module and the at least 
one code. v , . L „, f; ; ■ 

Thus, ; in the method according to the; invention r> 1 
more steps of the application mechanism; are cairiecj'.J ^ 
out on the secure application module than jn .methods^. J 
according to the prior art. This saves memory spacepn * 
the integrated circuit cards. and simplifies management J 
of multiple plications on integrated circuit car^s.^ J ^ 
Since the available memory space in secure t a[iDpii r / 
cation modules ; is less critical than on integrated circuit 
cards the number, of po^ibje access' rights may. be . 
rather large. Access righte may be.defined jn more \yaysi ( . 
than only read or write. In accordance. with, the inyentipn" 
access rights may relate to creating, erasing, increas- ^ 
ing, decreasing, validating, marking, and verifying serv-' ; 
r ice slots on the integrated circuit card and to np^ifying 
additional data parts if present. These are driiy exam- 
ples: other types of access rights may be. jmplemented 
on the secure application module. . . ,„*y 77 . , 

In an alternative embodi merit ihe metjiqci cSefined t 
above is characterised by the following step prior to' th 
step of checking predetermined.access rights in step a: , 
reading out service data from the service slot and stor- 
ing in the secure apppcation module a, predet^mined ^ 
data part of the data which has to remain unchanged; 
and by the step of carrying but step^b. without changing . 
the predetermined part of the data on the irrtegrsrted cir- 
cuit card. .. . . .-,-.*■ * v - 1 

Brief description of the Drawings . . . , . ^ 

^e pr^errtjrwention wi)l,b , 
reference to some.dr^ngS ^.%these dr^ngs : ^e;b*nly 
meant to illus&ate the present jrwentipri and riot to^limit 
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its scope. - ; 

Rgure,1 shows processes to, support integrated cir r , 
cuit card services like an, "electronic pur$e n facility; 
figure 2 shows a schematic flow diagram of method 
steps carried out in an integrated circuit card, a ter- 
minal, and, a secure; application module, respec- 
tively, to support such a service in accordance with 
the prior art; ; / > . , . / ,„ 
figure 3 shows; a structure for several secure appli- 
cation module facilities; 

figure 4 shows a service application environment .. 
on an integrated circuit card which may toe used for 
services of the same type, originating from different 
application providers (generic service, stats); ? 
figure S.shows a. structure of an alternative service 
application ienvirpnment for services of, different 
types, originating from one application provider oply 
(dedicated.serviceslots); 

figure, 6. shows a structure of a service application 
environment; of a secure application module in 
accordance with the present invention; - 
figure ? shows, a secure application module and its 
relation between several parties involved for provid- 
ingmnd fadlitating a service; 
figure 8a shows a schematic flow diagram of 
method steps carried out on an integrated circuit 
card, a terminal and a secure application module, 
respectively, for carrying out one of the following 
service actions: creating, erasing, or modifying a £ 
service object; \ * / i. 

figure 8b shows an amended flow diagram of the 
one shown; ia figure 8a, which illustrates . steps for 
carrying; out one; of the following service actions: 
increasing; decreasing, validating, and marking an 
existing service object; 

figure 9 shaman example of the exact structure of 
a service slot. 

Detailed description of t he embodiments 

As shown in figure 1 , in accordance with the^state of , 
the art, an integrated, circuit card 1 may be loaded with 
on or more services, like an "electronic purse" facility. 
A user 5 may insert the integrated circuit card 1 into suit- 
abl connection means (not shown) of a terminal 2. The 
terminal 2 is coupled to a secure application module 3. 
A data collect system 4 is coupledto the secure applica- 
tion mbdule :3 via the terminal interface.. The connec- 
tions between the terminal 2, the secure application 
module s, the data collect system 4, and the integrated 
circuit* card, 1, respectively, may be either by conven- 
tional wires; opticakfibres or by any wireless transmis- 
sion technique. 

The terminal 2 operates as ,an interfacerbetween 
the integrated^ circuit card 1 and the secure application 
module 3. f \ ? ■-?.< t vr^> v 

: ln order to ;faci|itate the description, 1 several defini- 



tions used will be statecliir^tly u . , 

Service type : the type of j card-related service to be 
used by a card holder 5. Examples of service types are 
the electronic purse, loyalty! counters, loyalty coupons, 
5 ( identifiers, subscriptions, tickets, e.g. to be used for 
parking, public transport, cinema, concerts. 'etc.. 

Service application : the, set of necessary service 
objects to be stored on the integrate^ circuit card 1 arid ' 
on the secure application module 3, to be us^for the 
10 exploitation of the service. Examples of service bbjedfe ^ 
are: loyalty points, tickets, subscriptions," etc.? , / " ^ ! 

Service parameter : a service object that is* neces- 
saryforthesj^ure application ^ 
. Hate a seiMck^pplication, e.g . the application, identif ier, 
15 . service identifier, ^ etc.. ^ . _ [ 

Service action : the ( authorized) execution of one or 
more . software, routines v^ich results ^ 
- s :,- tion, creatiqn, or eliminafo^^ for 
example, Jte creatiph or .verif icatipn of a. ticket or the 
20 increase or -decrease of loyalty points on a loyalty cou- 
. pon. ^ ... ; . V. 7".. _ .' . . , 

Service access rights : a defined authorization rule ! 
f for the use of , a ^ certain service action 

mined terminal; ,$bme terminals may, for example, only 
25 have the ''rig Wlpread the number, o]f lpya(ty points on a 
integrated circuit card 1 . whereas others may have the 
authorization to modify 'this number of loyalty points. ;* 
Service object : the service .related data structure 
that is securely stored on the integrated circuit dard and 
30 which x^nbe modified by a service (object) actibn (e g. 
tickets, coupohs,, loyalty, counters) ^ f .* ^ [ 

Hardware provider : the party which provides trie 
integrated circuity card t to the' card .issuers and ,the 
secure application module 3 to the card acceptants. 
35 These integrated circuit cards 1 and secure application 
modules 3 will be provided with basic applications for 
the use of, for instance, the electronic purse. Part of the 
memory of the provided integrated circuit cards 1 and 
the secure application modules can be used for the stor- . 
.40 age of further applications to be determined by the carcf 
issuer/card acceptant. , 

Card issuer : „the party which v issues the integrated 
circuit card 1,tp customers, this party determines the 
optional . applications on the integrated circuit cards 1 , 
45 usually, after a legal agreement with the hardware pro- 
vider. . li>: ,, .. .. .. 

Card acceptant : the party which buys the neces- 
sary secure appiicatipn modules 3 from the hardware 
provider in order to offer several caret-related services to 
50 the card holders 5. These secure application modules 3 
must be linked to the terminal(s) 2 of the card acceptant. 
The car^d A acpeptant ^determines the optional applica- 
, tions on the secure application module 3, usually after a 
c legal agreement with the hardware provider. - . ; ' 
55 - Aoolication 1 provider : the .party which facilitates 
; : f these card-rejated services, by means of storipg service 
v appiicatiqrj'n^ule^ : .on the integrated; circuit card ,1 anc} 
on thje^g^r^appliratipn' modules 3-.;Th1s party, rpust 
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also provide the necessary teritinal software to be 
stored in the terrrrinal(s) 2 of the card accfeptant 

Service provider : the party which (financially) 
exploits the* card-related service offered by a card 
acceptarrt and facilitated by an application provider. 5 

Service acceptarrt : the party which establishes the 
direct link 'between the card holder 5 and a certainserv- 
ice via an ori-jirie service host or via an off-line service 
terminal 2.* this party pertbrms the'service actions on 
the stbVed Service object, for which it is allowed to use. 10 • 

Card holder 5 : the" customer who uses tHe irrte-^ % 
grated circuit card i for several services by rneahs of 
establishing thfc necessary link between tfife integrated ■ : 
circuit card 1 and the terminal 2\ e.jg., by inserting the 
Chipper in a retailer's reader or by rommunicatirig via a' is 
Tele-Chipper®'. % ; , '^IZ^L V'., .. 

shown in figure 1 ; the' terminal 2] dbr^ls'aiiy ! \ v 
service transaction after a customer "5 has 'Sonnected 
his integrated circuit.card 1 to the terminal 2: TTie term!-' 
nal 2 performs any service action to be made and 20 
updates the service object on the integrated circuit card 
1 . At the same time, the terminal 2 perfbrmsihe riebes- 
sary actions on th£ secure application mbdui^ 3. ; zk 

The data .collect system 4 collects service parame- 
ters from and loa&s service parameters on ' the secure '25 
application mbdule 3 in a collection session/ " v y 1 ' 

The col I lection session as* indicated in figure ' r is 
known tb^persfcns skilled in the art and is not explained 
indetail here. \ ^ ♦* • / * \ 

As indicated above, several multiple application 30 
authorization mechanisms have been described before, 
like in ! US-A-5.473.690, WaA-92^6451^ -EP-A- 1 
0.640.945. £^^.644:513, WO-A-87707060; and EP- 
A-0.262:025 andEP-A-0.661. 675. These j^o^'murti- ; 
pie application authorization mechanisms share a diriect 35 
memory access structure, 'i.e., wrthout drrectbri^s athd ; ' 
files structures. A secret code C*is used for aocessing 
the application with an identifier I on the integrated cir- 
cuit card 1 . Whenever a secure application 'module' 3 '* 
wishes to access this application it must be able to gen- ao 
erate this secret code C. This secret code G may be - 
encrypted when it is supplied to the integrated drcuit 
card 1 to avoid its disclosure to the outside world. Alter- r 
natively, this cede C may be processed with a message 
authentication code (MAC) in order to avoid any modif i- ~* 45 
cation by the outside world. As a further alternative, this" 
code C may be supplied directly A control mechanism 
on the integrated circuit card 1 may count how many 
times a wrong code C is supplied: 

A second feature of all these known mechanisms is 'so 
the presence of an access table ? on the integrated drcuit * 
card : 1 . Mostly, such a table comprises a plurality of 
entries consisting of 1) the secret code C for a specific* 11 * 
application. 2). related memory locations M on the irite 1 ? - 
gratdd drcuit card 1 used I by that application (e^i refer- ss 
ring to zones.vnumbef of bytes, offsete; t records/- etc.) J,i 
and 3) related access rights Applicable io'trts-applira-^- 
tion (e.g: read/write ri^iis, PIN; etc:): When v either r ~ 



option 1 or option 2 is used a secret key Ks is required. 

Figure 2 shows a schematic flow diagram broadly 
summarizing the mechanism according to<the prior art 
when writing data D on a memory location M of the 
application related to the code C. Four phases can be 
distinguished: the initialization phase in which several 
parameters "are stored in 'the integrated drcuit card 
(ICC) "1 and the secure application module (SAM) 3, the 
application access phase in which the integrated drcuit 
cardl checks whether the secret code C as supplied is 
correct, the application request phase "-In which the 
request to write data D on the memory location M is 
made, and the request authorization' execution phase in 
which the terminal is authorized to' write data on mem- 
ory location M given access rights A and code C. The 
use of random lumbers RND is optional but is required* 
to avoid so-called "replay attacks". A random number- 
RND is used- by the secure application module 3 to 
encrypt the code C when the secret code C is* to .be i 
transferred from th§ secure application module 3 to the' 
integrated drcuit card 1 . The integrated drcuit card i is: 
equipped to decode the encoded secret code C. Thus, 
the terminal 2 when transferring the encrypted secrete 
code C from the secure application module 3 to the inte- 
grated drcuit card 1 does not know the value- of the; 
secret code C and will not be able to carry out any fur- 
ther action on the integrated circuit card 1 without being - 
authorized - ■ - ! - j u- .-. u. ^ 

Theflow diagram of figure 2 is separated, into three 
parts relating to the integrated circuit card (ICC) .1; the 
terminal 2, and the secure application module (SAM) 3, 
respectively. - - ■ i * -? W:* 

In step 201 ; the' integrated drcuit card %;stores; the 
following set of parameters for an application: an identi- 
fier F; a secret code C; a memory location M, and access 
rights A. ; . v <v ^ 

In step 202,- the integrated drcuit ^ard,1 stores a 
secret key Ks. « ^ * 

In the initialization phase, in step 203, the secure 
application module 3 stores an application identifier j; 
and a secret code C\ In step 204, the secure application 
module stores the secret key Ks. " :\ ~ f ; ' \ c 

For the same application, it is required that I = Y 
andCsC'. — ■■ ■•- * = ✓ v-.-.i *: 

In the application access phase the lowing steps 
are carriedotit 4> *"-;•;;' ; , > no 

In step 205 the integrated circuit card 1 generates a 
random number RND which is stored in step 206.n . * : ; - 

In step 207, the random number RND is transmitted 
- to the terminal 2. * - ' > - . ^ 

Step 208 indicates that the terminal 2 is waiting for 
receipt bMhe Vandom number RND. As long as the ran- 
dom number RND has riot been received. the terminal 2 
remains waiting. . r ■"• ^ » 

' As scbn as the 1 terminal 2 has received the random 
number RND ^transfers the random' number RND,- in 
step 209, to the secure application module 3. 

Steri 210 indicated -that in the application access 
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phase the secure application module 3 waits until the dom number RND in step:227 to the terminal 2. 

random number RND has been received: Step 228 indicates that the terminal 2 is waiting 

As soon as the random hiimber RND has been r ■ until the random number RND is received. 1 ; : 
received the secure applic^ion mc>dule 3 computes the If so, in step229, the random number RND is trans- 
value of a parameter Y in accordance with: v ^ s ferred to the secure application module 3. ■ ■ < 
- o l .■ Step 230 indicates that the secure application mod- 
: - — ■° : :==Enc(RND,C , )Ks ' s ule 3 is J waiting until the* random number RNDhas been 
•-.••A..; *.; .? v '■■ ■ received. > .s - " - • & yj.o-- .v.< x: 
Thus? the parameter Y is an encrypted form of the After the terminal 2 has transferred the random - 
secret code C\ the ; value of Y being determined by the 10 number RND>in step 229 thci terminal 2, in step ^231,' , 
value of the raridbm nurhber RND as received in step starts the write operation by sending a write jrequ^st^o 
210 and by the secret key Ks : A ■ .* rV the secure application module 3. ; • • • .w.'<- ^ > v 
In step 212, the secure application module 3 trans- Step 232 indicates.that the secure application mod* / 
mits the application identifier r and the parameter Y to 1 ule 3 is waiting until such a write request has? been - 
the terminal 2. ^ J - v % -> - ^ - v 15 received.^ If :so, it: computes, in step 233, > the value of 

Step 213 irklicates that the terminal 2 is waiting for parameter Y in accordance with: ? v --,r. 

receipt of the application identifier i' and the parameter •:- ■ < ,v ?s% • ; ; ^ .r r 

Y. "*--*'"■■ — ■■- - ' ■'■ " '< - ?k:Y::^Iv1AG(RND,iD,M)Kso - - ^ 

As soon as the terminal 2 receives the'applicatiori ; ^ ^ - : • : ; ; 
identifier T and the parameter Y, it transfers the applica- 2c - Thus;, Y is obtained by a message authentication 
tion idehtifierraridtKe code (MAG) ^operation on the values, of the random- 
curt card 1: I ? ^ number RND; the data D and the memory location M by .. 
St^ J 2^5 indicates that the integrated circuit card 1 * using secret key Ks. < i • ■•v 
is waiting until it has received the application identifier T In step 234; the secure application module 3 trans- 
and the parameter Y. . 2 s mits Y to the terminal 2. v *r r.j ■ : : , - :i 
As soon as the application identifier T arid the - Step '235 indicates that the: terminal 2 is waiting 
parameter Y have been received the integrated circuit until Y has been received. *■ ■ ^ . : : 
card 1 searches the entry on the application identifier l\ If so7 the application authorization execution may ; 
asirxlicaftkl ihstep 216. * : ' ( • r ■■'<• start. ^ r " •• ■■■■ ■ ' .- •■>•-: .v-- ■■■ 
Then, the integrated circuit card 1 computes the j so In the application authorization execution phase the 
value of a parameter X in accordance with: : terminal 2 starts with a request to write data D on mem- 
n r. , c r v : \ -•- c - - ory location M in the integrated circuit card 1 given the 
l — c X ^ Dec(RND,C)Ks ' ; ■ ^ computed valuevOf Y This is indicated by reference 
" r;; ' vr "->-\ * * ' .■ ■ - — : • ' --^ - number 236. : - v.; ■ r - - - ^v.; 
Wheh-de iScref code ; & is equal to the secret ccxle ^5 In step 237 the integrated circuit carder waits until 
C\ then, value of parameter X needs to be equal to - ? such a write request has been received, 
the value of' the parameter Y This 5 equivalence is tf so, the integrated circuit card 1 computes the 
checked in step 218 where a Boolean parameter R is value of parameter X in accordance with: 
computed in accordance with a Boolean operation - ■ ' ^ 
x = Yf : ^ v ; , 40 X := MAC ( RND, D, M) Ks. 

ih^step 219 the Boolean value! of parameter R is ^ . t : 

transmitted to the ^terminal 2. r ' ; Ihus, ti the value of key. Ks has .been properly , 

The terminal 2 is ! waiting in step 220 for receipt of stored both on the integrated circuit card t and the 

the parameter ^ R/ As soiih as parameter R- has been " secure ^ application module 3; X will be equal to Y This is 

received/ iff step 221; the terminal 2 checks whether R - 45 checked in step 239, Where the integrated circuit card 1r 

= tru^! if hot, the terminal 2 will generate an error mes- - computes the value of Boolean parameter R in accord- , 

sage in ; st6p 222 which may be shown to the user = ance with X === Y? • : £ n 

through suitable display means (not shbwh). r In step 240, the integrated circuit card 1 establishes 

If R*s= true, the application request phase 1 may start. - whether the termihal 2 is authorized to write the data D 

lh f the application request phase the terminal 2 " so on memory location M, given the values of the access 

requested in step 223,^ the' integrated circuit card 1 to v rights A ; ahd the secret code G: If not, in step. 241, the 

gen^^eVnar^mWrTber^RND.'' v ' v } r '■>:• int^gratecl^drcuit ca'rd 1 'may generate an errormessage. 

Step 224 indicates that the integrated circuit card 1 which rriay be sent to the terminal 2 for display on drs- 

is waiting for such a requests ^ h-. ~ ■ play means (not shown). •> i 

After receipt of said request; ih step 225, the inte- ss : - - If the terminal 2 is authorized to write; then, the inte- 
grated Circuit card 1 generates a random-hurriber RND; ^ grated Circuit card 1 will write the data D; on -memory] 
whichlslsl^eci'- in 'st^'2^6 : . Vi " ' :^ V" * locatio)ri : M; as indicated in step 242: ^ i. -v-v- 1 u > r 
TfierCthe irite^tetf drcurt card Vtrar^rhits'the^n- o: 1 ln T step : 243; the integrated drojit card -1 transmits 
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the value of Boolean parameter Rito the terminal 2. 

Step 244 indicates that the terminal 2 is waiting 
until the Boolean parameter r has been received. 

If so, the terminal 2 evaluates the Boolean parame- 
ter R in step 245 to check whether the write operation 
has been executed correctly. * 

Steps 246', 247 and 248 indicate the- end 'of the 
processing on the integrated circuit card 1. the terminal . 
2 and the secure application module 3, respectively. 

Although figure 2 relates to a write operation it may 
be clear to a person skilled in the art that this is ran 
example only. Read operations and other, operations 
may be processed in the same way, in accordance with 
the prior art- - - : - . -i.V- ^ *;£r.:v*v I 

Thus, from figure 2 it may beclear, that, in-accord- . 
ance with the prior art, in multiple application authoriza- 
tion mechanisms, the integrated circuit card 1 
comprises a table for any individual application. Any of 
these tables comprises an application identifier I, a 
secret code C, an indication* of the memory; zones <M 
where the application has been stored; ar^a definition : 
of access rights A. optionally linked, to more than 7 one . 
service acceptant. * ;j .■>;*>■ *: 

Contrary 'to > this known . mechanism; ; ?the, 'multiple 
application authorization mechanism according to .the 
present* invention is based oh a directory and file struc- 
ture in the memory of the integrated circuit card: 1i. More- , 
over,; in accordance with, the present ;inventiop^no 
access right tables are stored on the integrated circuit 
card 1 itself but are . stored in the secure application 
module; thus, saving memory space in the integrated 
circurtcard 1. . ;■. - -k r : v *\-s V :><:• } * 

In practice, on one physical secure: .application ■ 
module 3 both an electronic purse application and one 
or more other services: must be implemented. , These 
services must be clearly separated from one another. 

In accordance with the invention, a "service slot 
mechanism" is used to facilitate the service applications . 
other than the already existing electronic purse applica- 
tion. This will be explained below. 

Figure 3 schematically indicates that within the 
secure application module 3 a service slot mechanism 7 
must co-exist with an existing electronic purse media- - 
nism 8.* Both the service slot mechanism 7 and the el.ec-. 
tronic purse mechanism 8 are implemented by means 
of generic seajre application module facilities, such as 
internal files and an internal finite state machine. ~ s 

Below, an .example of using service slots, will be 
given. In this example the. previously stated definitions., 
will be used which are. thus, further clarified. ; - 

-It is assumed that a "generic seryjcejslcrt"-, (which 
will' be explained with, reference to figure ,4>Js%gsed in , 
the example., rf one of the definitions given above, is \ 
used, it is printed in italics. ,i i^. /co c^c^r- -v 

A local shopping centre (seryice provider). decides 
to begin-a regional loyalty scheme\fbr the frequent yishv 
tors (card holders) of the cerrtre^The.wsh of thegcentre^ 
is thatall retailers (service accepfan(s);Whidi ar&partic- 
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ipating in the loyalty scheme must be able to safely store . 
points (service 1) on the integrated circuit card 1. Most 
of the retailers are already accepting the integrated cir- 
cuit card 1 for the payment of small amounts, i.e., the 
integrated circuit card .1 already serves an. electronic 
purse application. The idea is that if the customer (card 
holder) has collected 100 of these issued points he can 
exchange them for a loyalty coupon (service 2) at a spe- 
cific loyalty terminal 2 on a specific location in. the cen- 
tre. Then this coupon can. only.be. exchanged, tqr a 
specific product at the shop of a specific retailer 

The shopping centre agrees, with the hardware 
provider : and the card issuer concerned -that two 
"generic service slots" are used for the implementation, 
of the loyalty scheme (service application). In order to : 
use the integrated circuit card ,1 for theloyalty scheme.* 
the hardware provider, which in this case is alsp the 4 
application provider, must provide the secure applica- 
tion modules 3 .of the participating retailers with the nec : 
essary service, parameters. ^These necessary. service ; 
parameters will be loaded, into, the secure application , 
module 3 during a collection session (see figure v 1), 
which is already facilitated- by the. hardware provider- 
Therefore, the hardware,provider must have the secure,. , 
application module identifiers at its disposal. By means, , 
of these service pa r ameters the retailers ^are able to 
perform some service actions. . . r ... - v ■ , 

At the normal payment terminals 2, the retailer must 
be able to increase a loyalty counter on the integrated , 
circuit card 1 and to accept loyalty coupons that are 
stored on the integrated circuit card 1. However, the , 
retailer must no be able to decrease the counter or to 
create loyalty coupons. , In other- words, the service 
access rights for any retailer concerned, i.e. any termi- 
nal 2 : concerned, must be well defined. When increasing 
the loyalty -counter or accepting . ajJpyalty.OTupon the, 
retailer stores a "stamp" on the integrated circuit card 1 
in order to depict the location of the. last Joyatty transac- .. 



tion. 



When creating loyalty points, a loyalty counter in the 
secure application module 3 of the terminal 2 con- 
cerned will be increased by the issued arriount of points. 
This is also done for the creation of loyalty coupons at 
the loyalty terminal.. The- value pf these TOuntei^wiM 
also be collected by the hardv^re provider during a col- 
lection session (see figure 1} and will then.be distributed, 
to a central system of the centre. In order to be able to 
administrate the, saved points per card holder, the joy- .'" 
alty system must use loyalty transaction records thatar 
- processed by a centraLsystem which may be imple- 
mented as a personal computer. Jhen,*rf a cu^omer .5 
loses or damages his integrated circuit card i the shop-, 
ping centre will .be able to restore the collected; amount 
of points on a new integrated circuit card ;Ul L * r c - v 

In order Jo limrt,^e;number ; of^ppints tq.be, issued, 
eacr>: payment terminal must be abie- to^issge^e.g^,^ 
10,000 loyalty points. Also, the retailer must pay, a pre- ; 
determinedjamountof money, to a antral shopping cen- 
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tre's account for each point to be issued. Therefore, the - 
secure application module 3 of the terminal 2 con- 
cerned must be reloaded with 10,000 points, each time 
that all the points have been issued (e.g. once a. week). *■ 
The reloading of the secure application module 3 will be 5 
handled during the collection session (see figure T). 

After having arranged all this, the retailers aire able 
to accept the integrated circuit card 1 for their loyalty 
scheme. In order to enable the customer 5 to participate 
in the loyalty scheme; the retailer must allocate two 10 
"generic service slots" on the integrated circuit card 1 . ■ 
One of thesie "generic service slots" is used for the stor^ 
age of points and another for the storage of coupons. Jf l 
the customer 5 has two service slots available he can? ; <- 
authorize the allocation by m^ans of entering hisPIN.. 15 
Only for the allocation of the slot the customer's PIN is 
required but riot for the storage of points or coupons. 
When a retailer has allocated two slots on the integrated^ 
circuit card 1 an allocation counter in the secure appli- 
cation module 3 is increased by two. Based on this alio-: 20 
cation counter * the* hardware provider charges the 
shopping centre with a certain amount of money. During 
a collection session (see figure 1), this allocation coun- 
ter is read in a secure way 1 

In accordance with the invention, the integrated cir- 25 
cuit card service types (e.g* a loyalty points service), or 
groups of service types, will be stored in one service 
domain, protected by a unique key (one service domain 
is equal to one set of files, profile, data, and additional), 
i.e. one common directory on the integrated circuit card 30 
1. This directory contains several "generic service 
slots 9 . Any of these "generic service slots" comprises .:• 
the data for brie Service application. > "Generic service - 
slots" will be used for services of t he same type for the ; 
same group of tvbesV originating frorri differ ent applica- ;35 
tion providers . - " - : ' : - 

Each service domain will be protected by a unique 
set of cryptographic keys Ks1, Ks2, see figure 4. Thus, 
any of the generic service slots belbhging to the appli- 
cation environment will be protected by the same two 40 
keys Ksi and Ks2. In order to prohibit the reading and 
writing of these generic service slots by unauthorized 
parties arid to necessitate a PIN when initializing a 
gen ric service slot, the generic service slot must be 
subdividedUntb' k prof ile part aind a data part. This is 45 
indicated in fijgure 4. The profile part will function as an 
authorization mechanism for each of the generic serv- 
ice slots. This mechanism must always be used in addi- 
tion to the cryptographic security architecture of -the 
application' environitieht (directory) concerned. so 

As shown in figure 4, the prof ile parts of the generic 
service slots present are grouped together within a first ^ 
file: Moreover, the data parts of the generic service slots 
present are grouped into a second separate file. 4; - 

Any of the generic service slots may comprise an 55 
additional data part for storing additional data. The addi- 
tional data parts of the generic service slots are 
groupfed together into > a third separate file. ^A-r*- i 



Any generic servic£ ; slpt i within the application 
environment (directoryj.can^easijy be found bo using a 
record number RN(i). .For any. i, the profile parC data 
part and additional data, part concerned are stored in, 
the same record RN(i) of the three different files. 

The profile part may, for; instance, comprise 20 
bytes. For any application,: the prof ile- part .ppncerned , 
contains a unique application identifier and a slot labe|. nH 
In a preferred embodiment, the profile part of a generic ; ; 
service slot comprises data as to an expiry, dat^. c This 
expiry date refers to a date when the service poncernecj ;: 
expires for Re integrated circuit card 1 concerned. From 
that day onwards the generic servipe slot concerned is , 
available to bemused for any other service t application, ... 
i.e., the data in the generic service slot concerned may 
be deleted andrthe generic service slot concerned may 
be written by another . semce ai^on^aftically ^ ; 

The deta part,pf the generic service slot.contaips 
data which depends on the service type for which the 
generic ^ervice sjot is.used. For exarrple, the data for a 
loyalty schemejwill be different from the data for a sub- 
scription:; ^:f. ■■>.;■ - • . • .;. ;, : , : ■ , 

The additional: data part depends on. the, service .„ . , 
type. It offers the possibility of storing additional data 
when required-,? For some applications no additional, 
data part: is required^ , ; 0 >. ;;. : , : j ; - ■ 
A detailed description of the structure of a generic ... 
service slot. will be given later, with reference to figure ^. 

Figure 5 shows an alternative structure for an appji- 
cation environment on an integrated; circuit card \. this 
alternative structure is applicable if one: single . applica- 
tion provider wishes to facilitate different service types, t 
e.g. loyalty- points, tickets, subscriptions, etc., . In such a 
case several* different generic . service slots,, as 
explained with reference to figure 4, may be used. How- 
ever, this would result in 1) performance loss due to the 
required application switching time and 2) memory loss r 
due to the presence of identical prof He parts. Therefore^ 
it must also, be possible for an application prpvider to. 
use different service types within one application envi- ; 
ronment. - / 

The required service objects for these different 
service types will, then, be stored into "dedicated serv- { 
ice slots", as referred to in figure 5, These dedicated . : 
service slots will only be used for services of different 
t ypes, oriqinatino from one single application provider. 

For the use of such dedicated service slots only one 
profile part will be necessary because ail data parts are 
used by the same application provider. Hoyyever. due to 
the fact that the-corttents of the. dedicated profile part 
are directly linked to one; key environment (of the appli- 
cation provider), the single prof ile part does not have to 
be checked by the secure application, module 3 con- 
cerned.;:;^ \; - ; 

Thus, in the embodiment according- tafigure 5, still 
three different files ;(or two files when the file with .addi- 
tional dataparts is superfluous) are used. However; the 
fileJor the profile parts ooly ;Comprises,pne;singie, prof ile 
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part and, therefore, needs less rnembry locations than 
in the embodiment according to figure 4. ' 

An example of the embodiment according to figure 
5 is the situation in which one single public transport 
firm offers several different services and in which one or s 
more railway firms and one or more bus companies are 
operating as Service acceptants. Then, the different 
services may relate to storing "railway tickets; 1 bus tick- 
ets, loyalty points etc.. " - , r 

While the 'card service slots (figures 4 and 5) are- w 
grouped per service type the secure application module 
service slots are* grouped per application provider and ' 
stored into one single secure application module appli- • 
cation environment; i.e.. one single directory "oh the 
secure application module. For example, a retailer could 7 is 
provide loyalty points, loyalty coupons and loyalty cross- 
selling points whereas another organization could pro 1 : - s "- 
vide electronic tickets and electronic subscriptions on 
the same integrated circuit card 1. The secure '-applica"- * > 
tion module df this retailer needs only to control these - £0 
loyalty points,' loyalty coupons and loyairty cross-selling < 
points. The secure application module of the other.; 
organization heed only to corrtroPthe electronic 'tickets 
and th^ electronic subscriptions. Thus; the application ; 
environment on the secure application mddule r con- r 25 
cerned can be organized into different service slots, ^as ' - 
shown in figure 6. A secure application nrodule* service 
slot consists of 1 an i application service- definition.' two ^ 
application counters, a service floaty a - "service 
sequence counter; and service access rights df the ter-" 30 
minal concerned. The 'application service definition will - 
be used to "store the unique service identifier and, to 
determine the service typeP The application counters 
are an alidcation counter for administrating the number / 
of allocations, and atransactioh cotfntef for generating - 35 
a unique record transaction^ number. >The service float 
adminislrates' the^ number of issued/received: value 
units, rf; applicable: The service sequence counter gen- 
erates a- unique object number and administrates the 
number of created service objects. " J - *o 

The service rights must define the service actions 
which the secure application module concerned ' is 
allowed to perform. For example, a secure application 
module could be authorized for issuing loyalty points, 
i.e. increasing the loyalty counter on an integrated ar~. 45 
curt card 1- 6ut not for receiving loyalty • points, i.e,\ > 
decreasing the loyalty counter. The service rights will 
also contain the necessary parameters for the' use of. 
internal secure application module variables. ■ ■; *.< 

In order to ; assign a certain [ service to a secure -i-so 
application 'module service slot, the service parameters , 
must be loaded in the available service slot Hie loading < : 
of these parameters will -be protected by some crypto- 
graphic means, i.e. the cryptographic key Ksamvas* : ~ 
denoted in figures'? and 8* • - • ■*. ^ 55 

Multiple secure application modules irhay be :pro--vn 
vided by a hardware provider to each requesting_card rc 
acceptant which' : has a*cdnfract or agreement .with the $ 



hardware provider. Normally, each secure application 
module will at least be provided with the electronic 
purse service and with one or more other services facil- 
itated by one or more other application providers. The 
card acceptant's choice on which services to offer by his 
terminal can be determined during personalization of 
the secure application module but can also be deter- 
mined when the secure application module has already 
been installed at the card acceptants location. . 

As. schematically shown Jn figure - 7. the: secure 
application module 3 must facilitate a layered applica- 
tion and security structure. The secure application mod- , 
ule 3 will be provided by v the hardware provider and will , 
be used by the authorized card acceptant. ; ^ . > r 

The following conditions must be met: - . 

each secure application module 3 must be able to : 
facilitate applications provided ;by one or, more : 
application providers, ie.g, the provider of an elec- ; t 
. trohic purse application; t ■ <>k : co v -•%:•_ ■> 

each application must be ablejo fecilitate services 
of one or more service providers which are sharing v, : - 
one: service application- environment of a secure T . 
application module 3; t - ? r , _ , ; 

each service will be used by one or more service 
acceptants which are authorized by means .cf the t, : 
service rights defined: .* . > : - > ^ ; 

Processing service slots : • . , . ; ~ *j * - 

In order to use the card service slots, both the sery^ 
ice slots and the SAM service slot application must be / 
processed by theterminal. Now a description's givervof 
the possible service, actions, on slot profile. arri the data 
part-of the service j slots. The^ryice- actions wjli be ^ t 
divided into profile actions, which can be performed on 
the slot, prof ile, and object, actions which, can be per- 
formed on the data part, r v : v ; »- % 
The next profile actions have been defined: ?; , 

allocate service slot (only applicable:, for generic ... 
service slots); . - *< 

release service slot (only applicable for generic ^ 
-service slots); - , rv /^ ■>* ? 

* - block service slot (applicable for both : types); \ r 

* unblock service slot (applicable for both types);? >« 

* modify profile (applicable for both types). rV •„ - - ..r., . - 

The first two: profile actions will only be performed 
on generic service slots, while the last .three actions can >T 
be performed, on both dedicated service; slots. and 
generic service slots. If applying the last three actions ., 
on a dedicated application; the use^ol a-PIN;pan be ;< 
omitted. <\ , ?....; - . . +v,; ; - , •; . „ ±. * 

Allocating- a seryjce.slpt c - -: v.i - - ^ v. >r,;!;:t >: v r 

ff the SAM service slot application^ : tes t be^^initial-, J . 
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ized already, the terminal (i.e. the SAM) should be able 
to allocate a generic service slot on the integrated cir- 
cuit card. Therefore^ a free service slot must be availa- 
ble and the cardholder must have entered his/her PIN: 
correctly. Depending on application access rights, the 5 
terminal will.be able, to allocate a generic service slot. 
The next steps need to be performed: 

1 . checking th£ application access rights; 

2. checking of the service slot is empty; : > 10 

3. retrieving (the record number of) the free service 
slot on the card; 

4. checking the PIN of the cardholder; 

5. determining the expiry date of the generic serv- 
ice slot; - ' : : ' : w • - 

6. updating the allocation counter in the SAM; ; 

7. initializing the slot profile (using the application 
idehtrfier that is stored in the SAM). 

Releasing a service slot " ^ 



Next to allocating a generic service slot, it must also 
be possible to release a generic service slot. This will be 
handled by a similar mechanism as for the allocation of • ^ A 

a card ! service slot. However, instead of loading author- 25 Modifying a slot profile 
ization parameters, the service slot will be loaded with a 
certain fixed zero pattern (indicating that the slot is free 
to use). Only the application provider of the allocated 
slot can release its slot. But there must* also be an 
option that an expired siot can be allocated by an arbi- 30 
trary application provider. This could be possible, if a 
collection-date has been securely loaded into the SAM; 
The next steps need to be performed: 



3. retrieving (the reccrtfjiumber of) <the ; service, slot 
on the card; ' u o;^3r*t : V: ::. ' e;,„: 

4. checking the PIN of the cardholder; 

5. modifying the first byte of the slotprofile (using a 
fixed block-pattern). , - : 

Unblocking.aservice.slct :■. ~> % ? : ^:> , a : ; 

By means of this profile action; the status byte -of • 
the slot profile will be reset to zero. The autiipnzatio^ fpr 
performing this action depends on fteijapplication 
access rights as stored in the SAM. 

tf a generic service, slot has been unblocked .it cap 
be used again. The nextsteps need to be performed: - ■* 

Ivcheckihg the application accessrights; ^. 
2; (determining ; the n generic service slot tp . be 
unblocked; ttiLi *- ?«* - • - \-, ;^ ; 

3. retrieving (the record number of) the service slot 
r- on the card; ?; v< ; r 

4. checking the PIN of the cardholder; i 
5; modifying the first byte of the slot proffle (using a, 
fixed unblock-pattern). . ■ . v - 



By means of this profile action, the service provider 
can modify the non-critical data of, the slotprofile {e.g: 
the last 1 r bytes). These bytes could then be used to 
store additional data like a customer profile, a label, or 
other information; The next steps need to be performed: 
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1 . checking the application access rights; 35 

2. determining the - generic service slot to be 
released; ■ ■ ; 
3: retrieving (the record number of) the (expired) 
service slot on the card; 

4. checking the PIN of the cardholder; 

5. initializing the slot prof ile (using a fixed zero-pat- 
tern). 

Blocking a service slot v 

By means if the status byte that is stored into the 
slot profile, there is an option to block a generic service 
slot. This pption could be used when performing on-line 
sessions in order to maintain the integrity of the applica- 
tion (e.g. similar to the use of the reload flag of the card; 
electronic purse application). -> 

If a generic service slot has been blocked it cannot 
be used again, unless the service slot will be unblocked 
again. The next steps need to be performed: > * 

'1 : . checking the application acx;ess"rights; ■ ^ : 
2. determining the generic service slot to be 
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1 . checking the application access rights; ;* 

2. : determining the generic service slot to be modi- 

fied; ; ->^:' : ^ ■. ! rr-. v •« •;. . • • 

3. retrieving (the record number of) the service slot 
on the card; , . - >. 

4. checking the PIN of the cardholder; 

5/ modifying the non-critical data of .the slot profile, 
e.g. the last 1 1 bytes of the slotprofile (using arbi- % 
trary data). .•• ,' < 

The data part of a generic/dedicated service slot 
can be processed by several Object actions, depending 
on the concerning service (e.g. loyalty points, tickets, 
etc.). However, the secure application module must, 
always authorize the requested service: actions,: by 
means of the ; defined service access rights. The next 
service actions have been defined: ; * 

create service slot;- < - / 
erase service slot; 

.increase service slot; ^ r: *n \ 

decrease service slot; : : . ; : : ! 

v --- validate service slot; , zU< ^ >'\;; 

- "rrferkservice slot; ? r ; ; ^ i; : r : < 

'Verify^eivice'Slot;'.^;-^;- e^-s: v.- ■*/ ^ n.-.^ 

rnddrfy^additional data part. /»;>; J; ; :C 
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It is observed that when creating or erasing a serv- 
ice slot, step 3 defined above ("retrieving the free serv- 
ice slot") in the paragraph related to the allocation of a 
service slot, may, optionally, be omitted; <■.. 

Below, with reference to figures 8a and 8b, exam- s 
pies of service actions on a service slot on an integrated 
circuit card 1 will be described. Figure 8a is applicable . 
to the following service actions: creating, erasing, or 
modifying aservice object, whereas figure 8b is applica- 
ble to one- of the 1 following service actions: increasing, 10 
decreiasihgv : "vjalidating or marking 1 an existing service*. 
object - ^ 

Rgures 8a aiid 8b have been presented as flow dia- 
grams showing actions 4b be performed by the;inte- . 
grated circuit card 1 , the terminal 2, and the secure is 
application module 3, respectively Both the flow: dia- 
grams of figures 8a and 8b have been divided, irt four 
phases: initialization, application request and authoriza- 
tion, service action request and authorization, and serv- 
ice action execution, respectively. ;* : ^ 20 

In the initialization phase the integrated circuit card 
1 loads two keys Ks1 ;' Ks2. The same keys Ks1, Ks2 are 
loaded by the secure application module 3, which also 
loads a further key Ksam. This is shown in line 801 

The integrated circuit card 1 also writes 'an applica- :2s 
tion code C and a service code S* in its memory by 
using -key^Ks2, * i.e.; it allocates a slot. \ line 802^ The 
secure application module 3 writes, as is also shown in - 
line 802;' an application code C and a service code S as . 
well as application/service access conditions? A* in its 30 
memory using Ksam. After that, the initialization phase 
is completed. 

The application -request and authorization phase 
starts with a request' by terminal 2 to the integrated cir- 
cuit card 1 , which has been brought into communicating 35 
contact with the terminal 2, to select a file prof Be. The 
integrated circuit card 1 gets the request to select a file 
profile in line 803. i ' . ^ ? 

Line 804 indicates that the integrated circuit card. 1 
then continues to select the correct-file! - - , 40 

The next step is that terminal 2 requests- the inte- 
grated circuit card 1 to seek application code C and the 
service code S\ In line 805 it is indicated that the inte- 
grated circuit card 1 gets that request whereas, in line 
806, ;rt is indicated that it searches E for the application 45 
code C'and the service codeS * 

In line*807 it is indicated that the integrated circuit 
card 1 replies by returning the i record number RN' 
related to the application code C and the service code 
S\ This record number RN' is received by the terminal 2 so 
in line 807, and the validity of record number -RN ! ( is 
checked in line 808. , 

If the validity of the record number RN^is correct, 
then, in line 809. the terminal 2 asks the secure applica- . 
tion module 3 to generate a random number ;BND1. $5 
After the secure application module 3 ;has got/the - 
request (line 809), it generates such a random number 
RND1 , line 810, and stores it:in its^memory/HneSli, - 



In line 812, the secure application module 3 returns 
the generated random number RN01 to the terminal 2, 
which gives it to the integrated circuit card 1 . 

The next step, as indicated in line 813, is that the 
terminal 2 requests the integrated circuit card 1 to read 
the content of record number RN'. As is also indicated in 
line 81 3, the request is received by the integrated circuit 
card 1. 

Then, in line 814; the integrated circuit card .1. com- 
putes the value of a parameter Y: . , ^ v ,> 

Y := MAC(RND1 ^N'.C^Ksl . ' h , ^ ; ■ - 

Thus, the value of Y is computed by processing the. ran- 
dom number RND1, the record number RN', and, the 
application code C* with a message authentication code 
(MAC)jising key Ks1 ... - . u , 

In line 815, the integrated circuit card 1 transmits 
the application code G' and the parameter Y to the ter- 
minal 2 which receives them, as is also indicated in line. 
815. 

In line 816, the terminal 2 transmits a request to the 
secure application module 3 to verify the value of Y by 
transmitting the application code C, the record [nurnber * 
RN* and the parameter Y to the secure application mod- 
ule 3. . •>-. , 

After the secure application module 3 has received- 
these parameters (line .816), it stores the application 
code O' and the record number RN' in Jioe817.^<r - ... , 

In line 818 the secure application module 3 com-,, 
putes the value of Boolean parameter R in accordance 
with: ■ , - v •. ..: ' s -^..r .^o 

R := Bool (C'==C) 

In line 819 the secure application module 3xhecks 
whether R = true. ^ - c _ . 

If so, in line 820, the secure application, module 3 
computes the value of a parameter X: ^ ; , .. 

. X := MAC(BND1 f RN\C7Ks1 t . . . ; -i 

Thus, the value of X is computed by processing the 
random number RIMD1 , the record number RN^and the 
. application code C with a message authentication code 
MAC. using key Ksl . Therefore, parameter X Js com- 
puted similar to : the ; parameter Y. rf the ; keys^Ksl are, 
equal, X must be. equal to Y This is checked in lines 821 
and 822, where, f irst of all, Boolean parameter R is cal- 
culated;, in accordance.with: -R i = Bool (X==Y) , and, 
then, it is checked whether R = true. , <*.<'. u... + 

Jn line .823. the,value of Boolean parameter R is 
transmitted to .the terminal: 2, f which ; .(^ecks ; its value 
upon receipt. . ., t : ; . 

If the Boolean parameter R = true, the next phase, 
i.e. service action request and authorization phase, can 
be started. ^ ,^ t < v. -, . r . < 

In line 824, the terminal 2 requests the integrated 
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circuit caiti 1 to select a tile service. That request is 
received by the integrated circuit card 1 , still in line 824. 

Upon the receipt of the request, in line 825, the inte- 
grated circuit card i selects the correct file. 

Then, in line 826,; the terminal 2 asks the integrated s 
circuit card i to generate a random number RND2. 

The fec^uest is received in line 826 by the integrated 
circuit card 1. Upon the receipt of the request the inte- 
grated circuit card i generates a random number 
RND2 f line 827, and stores it in line 828. — ■ 10 

In line 829, the generated random number RND2 is 
transmitted to the terminal s which gives it to the secure 
application module 3, as is also indicated in line 829. 

ThenT in line "830, the terminal r 2 ' requests the 
secure application module 3 whether it is authorized to is 
carry out a certain service actibn, e.g. a write action, on 
the integrated circuit card i . The request is received by 
the secure application module 3 in line 830. The request : ' ' 
received refers tb a request to write service data D in 
recoird^humber RN given a service code S\ 20 

Then, in line 831, the secure application module 3' 
computes the value of Boolean parameter R in accord- 
ance with: 

R := Bdol(Rfsl ==RNj \ / 25 

In line 832, the secure application module 3 checks 
whether R = true. If so, then it is evident, Jhat the 
request relates to the correct record number RN. 

In line 833. the secure application module 3 com- 30 
putesBboieari parameter R in accordance with: " 

R := Bool(S'==S) 

Then, in line 834, the secure ^piicatbn nftedLile 3 35 
checte whether R = true. If so, thein it is evident that the 
request relates to the correct service. ; / _ 

in line 835, the secure application module's com- 
putes Boolean parameter R in accordance with: 

R ^ authorize (WRITE,C,S, A) 

Then, in line 836, the secure application module 3 
checks whether R = true. If so, then, the terminal is 
authorized to carry out the service action on the given 45 
r cord number RN in the integrated circuit card 1 , as 
requested: ' '. 

In line 837, the secure application module 3 com- 
putes the valuei of parameter X jn accordance with: 

X := MAC(RND2,S, D, RN)Ks2 

Thus/ the value 6f X is computed by processing the 
parameters (RND2, S. D. and RN) with a message 
authenticaitioh'cbde (MAC) b^ Using key Ks2. n ' 55 

In step 838, the parameter X is transmitted tb terrhi- 1 
nal 2. The terminal 2 receives the parameter X in line 
838 ahdcr^cksTHs validity in 1ihe839. 1 ^ - " 



After the 1 validity of Uhe-pararheter X has beeh 
checked by the terminal 2, : the service action execution <■ 
phase can be started. ^ - " 

This last phase starts with a request by terminal 2 
to write service data D in record number RN, given serv- 
ice code S and parameter X. the request is received by 
the integrated circuit card t in line 840. 

After the receipt, the integrated circuit card 1 bom- " 
putes the value of parameter Y in acc^dance J ; | ^ 

Sr := MAC(RND2;s,b,RN)r^2 

Thus, the value of Y must be equal to the value of X 
if the keySKs2 stored dn both the integrated drcuit card 
1 and the se&tire application module 3 are equal. w [ 

This equivalence is checked iniine 842 and 8i3^ 
First of all; Bbbleah parameter R is computed in accord- 
ance with: " ' :; ; ' ; 1 ; " ' 4 ; \ 

- R := Bdol(X==Y) 1 

Then, * ? in line 843, the integrated circuit card 1 
checks whether R = true. ^ - ; 

tf sbr ail checks made are positive and , in line 844, 
the integrated circuit card can fetch the record number 
RN. ■■ ' ■ ; : "■-'■' J ; / ' : * v " 

In line 845; the integrated circuit card 1 stores the 
service data D, as well as the service code S on the 
record Wuirnbef RN . i.e., it carries but the requested write 
action. 1 - ;:. 

Iri order to complete the service action, in line 846, 
the integrated - circuit card 1 transmits the value' of 
Boolean parameter R to the terminal 2. 

After receipt of the Boolean parameter R (line 846), 
the terminal 2 checks the content of the Boolean param- 
eter R, line 847, in order to be sure that the write 
request as transmitted in line 840 has been carried out 
properly. 

TTiose steps which are essential in carrying out the 
service action illustrated in figure 8a, have been out- 
lined by rectangular lines. The application of random 
numbers RNDV and RND2 is optional, similar as in the 
prior art. In practice, randorh nurhbers will always be 
used to avoid "replay attacks", as explained with refer- 
ence to figure 2. 

Figure 8b shows a flow diagram which is an 
amended flow diagram of the one shown in figure 8a. 
, The flow diagram of figure 8b illustrates steps for carry- 
ing out one of the following service actions: increasing, 
decr^in^, validating, and marking ah existing service 
object in an integrated circuit card 1 

Those steps in figure 8b Which are equal to the 
steps in figure 8a niave been indicated by equal line 
numbers. Their meaning wili not be explained again; 
there are ohfy some different steps in the service action 
request eihd : aUthorizatibn pha£e indicated by lines 
825a-825p and amended lines 830a, 837a, 837b. They 
will be explained below. " " ? ^ J 
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The main difference between the service actions of 
figure 8a (i.e. creating, .erasing, or modifying, a service 
object) and of figure 8b (i.e. increasing, decreasing, val- 
idating, or marking an existing service object) is that in 
the first case the existing data content of the service slot 5 
on which the service action, has to be carried out does 
not need to be verified, .whereas this is necessary in the 
tatter case When .carrying .out. the service actions 
according, to, figure §b only a certain part of the data, 
content of the service object is to be changed (this data 70 
part is called "D.var" in figure 8b whereas the remaining 
part of the data of the service object that is to remain 
iderticaMs called M pJixed M in f igure 8b)..ln ; qiderjto know 
the content of this remaining part, of the data D.fixecfjn _ 
lines 825a-825p', a secure read operating is carried out 15 
on integrated circuit card i. . . , , . .. \ - : .- s 

Again, in figure 8b, those steps which are essential 
to the service action are outlined in rectangular lines. . 

In line 825a in figure 8b, after the integrated circuit 
card 1 has selected the, correct file during the service 20 
action request and authorization phase, terminal 2 
requests the secure application module 3, to generate a 
random number RIMD3. , , „ .:, . * ifr - ft , 

Also shown, in line 825a is that secure, application 
module 3 receives the. request. . ; ^/,> (f 2 P 

After that, the security application module 3 gener- >, . 
ates a random number RND3 (line 825b) and stores it in 
its memory (line -,825c). Then, the , random : nurr^er 
RND3Js transmrtted to , the integrated circuit : card 1 
through terminal 2, as indicated in line 825d. r 30 

Then, in line 825e, the terminal 2 requests the inte- 
g rated,, circuit card.. 1 . -to. read , the content of^ record r 
number RN*. . , f . - - j , H , v . f ; .. ;; 

After receipt of .the .request (line 825e) ( the inte- 
grated circuit card 1 computes the content of a parame- . 35 
ter Y in accondancawith: , - v- 

Y := MAC(RND3,M\S\D')Ks1 " „,\ . 

Thus, the content of parameter Y is computed by 40 
processing the parameters RND3, M*. S', D' with a mes- 
sage authentication code (MAC) by using key Ks1. s 
Here, S\ refers to the service, code concerned and D\ 
refers, to the content of , record number RN*. which has~ . 
been read. * . . , - : . 45 

In line 825g, the integrated circuit.card 1 transmits 
the service cqde.S*„data D T , jand parameter Y to termi- 
nal^. ^ , . „ - r . v ... ' V 

In line 825h, the terminal 2 requests the . secure 
application module 3 to verify the content of data. D' on, so 
record number RN'. r 0 . ' . ; . c . , 

In line 825h, the secure application rnodule .3 
receives, the service code S\ the data^DV the record . . , 
nurnb^RN*. and the parameter Y. , - .. t 

... In line 825i.. the secure application module, 3 cpm-^; ss 
putes a Boolean parameter R in accordance with: ". : „ \ _ v 



In line 825j. the secure application module 3 checks . 
whether R = true. . 

The secure application. module 3 stores the service 
code S\ the data D\ and the record number RN' in its 
memory, line 825k. Those bits of the data D' which must 
remain unchanged, i.e. D'.fixed, is automatically - 
retrieved from the data D' by, the secure application 
module 3 and stored [in its memory, line 8251. 

Then, in line 825m, the secure application, module : . 
computes a parameter X in accordance with: , ; #v 

\ X := MAC(RNb3,S\D\MlKsi , . , ^ ■' 

Thus, the content of parameter X is computed, by 
processing the parameters RND3, jS\ D\ M\with.a mes; 
sage authentication code (MAC) by using key Ks1 . .> , . 

If keys Ksl on the integrated circuit card l.anc^the . 
secure^application module 3 are the same, the values of 
X and Y are to be the same. This is checked in the steps . 
carried out in lines 825n and 825o, by first computing a ;V 
Boolean parameter R in accordance with: ;t . 

R := BooI(X==Y) 

and then checking whether R = true. 

In line 825p the value of Boolean parameter R is 
transmitted to the ; terminal 2. where its content is 
checked. , : , - , , . v -. . 

Thus, after the method steps shown in lines 825a^ . 
825r, the part D'.fixed of data D'. which is to remain 
unchanged,. is read out from the integrated drcuit card 1 . 
in a secure way and stored in secure application module' 
3. . . - - * , : . . 

Now, the service action request and authorization 
phase mainly fbllpws.the same steps as have been illus- 
trated in line 826-838 of figure 8a However, jn iine;830, . 
the terminal only requests the secure application mod- [ 
ule aa authorization, to write the variabie pairt : p.yar of 
data D in record, number; RN. Moreover, the step ^carried,, 
out in line 837 in figure 8a, which has been renumbered 
into line 837b in figure 8b, is preceded by an additional 
step of calculating data D in accordance with the foilow- 
ingformula: . . : f ^ . - . 

% . D :=.D'.fixed + D.var . ,» \ ^ ; . 

Thus, the fixed part D'.fixed of data D equals the 
fixed part D'.fixed of the former data D', since rt has 
been previously read in the method steps carried out in 
lines 825a-825b and has been included into the new 
data D used in the service action- execution phase 
shown in lines 840-847. 

When comparing the flow, diagrams off igures 2, 8a, 
and 8b the following differences between the prior, art in . 
which no use of directories and files is t made, and the 
present inventipn are: v [ ,. ... \ : V-l r 7 v 

• ; " v -f, \ v c • .* ?» _ ----- : V . IT- 

the integrated circuit card.1 comprises no tables, r 
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with application identifiers/pass words, access 
rights and pointers to memory -zones; 
the application access rights A are stored on the 
secure application module 3; 
use is made of two keys Ks1 and ! Ks2 in the inte- 
grated circuit card 1 whereas three keys Ks1, Ks2 
and Ksam are stored in the secure application mod- 
ule 3; 

directory and file structures are used on the inte- 
grated circuit card 1 to support a security architec- 
ture; 1 - - ; ? : : r* . v y ■ y >. 
records and record numbers are used within the file 
structures to provide a security architecture on the 
level of different services and service providers; 
the check whether terminal 2 is authorized to carry 
out a certain service action on the integrated circuit 
card it is carried out by the secure application mod- 
ule 3 and not by the integrated circuit card 1 , thus 
saving memory space in the latter. 

Figure 9 shows one possible exact structure: of a 
service slot. The service slot is divided into three parts: 
file 1 , file 2, and file 3 (optionally). File 1 comprises the 
service slot profile' and is provided with status, applica- 
tion code, expiration date, application label (text) and 
some free bits: These free bits may, e.g..be used for fur- 
ther data for the service provider. 

File 2 comprises the service slot data and is pro- 
vided with the value (e g price of a ticker or a loyalty 
counter), validity, service code, and some free bits. The 
validity bits are used to indicate whether the ; service 
object is still valid, e.g., whether a coupon or ticket can 
still be used. 

Since the service actions creating, validating; and 
marking are only allowed' to change a variable part 
D.var of the data D; the free bits of file 2 of the service 
object are divided into a creation, validation, and mark- 
ing part. The creation part is written once when creating 
an object, the validation part is written a limited number 
of times; depending on the value of the validity counter, 
whereas the marking part can be written an unlimited 
number of times. 

File 3 comprises a predetermined number of free 
bits to be used to store additional service slot data. * 

In -an alternative embodiment of the invention, a 
provision is nhade to temporarily store data from a serv- 
ice slot in ah integrated circuit card into a memory of a 
third party The third party may be the service provider 
but can, 'alternatively, be a bank, a notary or a card 
issuer. Such a provision may be useful when the card 
holder has. e.g.. bought a ticket for a concert months 
before the concert will be given and the card holder 
does not want to loose his ticket. i-v f 

-Storing the data frorri the service slot in the inte- 
grated circuit eard'into the third party memory must take 
place in a secure way- *v .->■>>; " ,11 

: In order to carry out such a temporarily storage the 
third party will use the standard service s\6X functional- 



ity, however, without the restriction determined by the 
unique application identifier stored in the definition part 
and the service identifier stored in the data part. The ; 
third party must be provided with a secure application' 

5 module s arranged to read the data (i.e., slot definition, 
slot data and additional slot data), to verify the service 
slot, and to write data (create a service slot and erase a 
serviceslot). v . , v " '. r - ' \/ '.. : .t r '\. : • . , 
The following steps are to be carried ^ut tpr suphian 

io additional service. : r ; ^ ;> rf o: ^ c JV 

The relevant data . piustbe securely read out from 
the integrated circuit card concerned which ; includes the 
following substeps:* , , ■ .. . ^ ■■ : . 

is - reading put the integrated circuit card ID; Vi 

selectingvthe servicer slot related f to ,the ; integrated 
circuit card IP; c - ., \ v. \i :* :•• j ■■; t: 
reading^d.yerifying the service slot date, service 
slot definition, and, if applicable, additional service 

20 •.• slot data; ; • - 

storing a stamped MAC and random number of the 
service slot definition and the service slot data in 
order to allow a.o. the card holder to prove that the 
card service slot concerned was provided with the 

25 . data to be temporarily stored in, the. third party 
memory ; a time stamp could be used as arandom 
number; ; - ••. - ; . ■. r , , -. . av ) 
securely storing the ID, service slot definition, serv- 
ice slot data and additional service slot, data, -• if 

30 present,in a third party menpry; Vf ^ 

- erasing serviceslot and releasing service slot defi- 
nition in the integrated circuit , card, 

.When the .card holder wishes to have his data 
35 retransmitted from the third party memory ~to ; his card, 
the next steps need to be carried put: 

verifying the user PIN, if required; 

- verifying whether, the data in the third party memory 
40 was read out from the integrated circuit card con- 
cerned by checking whether the stored ID equals 
the integrated card ID; , , -•• 

- selecting a free service slot; 

- allocating a free service slot with a service slot def- 
45 inition; 

writing service slot data, and possibly additional 
service slot data in the .selected free service slot 
(create service slot, possibly modify service slot), 
and -<• , ;.. ;• 
so - erasingthe third partymemory. 

In a further alternative embodiment, instead of 
transferring the content of a services slot to, a third party 
memory-one could lock a service slot on the integrated 
55 r circuit card itself. This could be done, by ajele^hipper® 
or through Internet, e.g., by changing the content of a bit 
in the'service.slbt definition Then, tye use-pf this serv- 
ice;slotwoutd be temporarily blpckedi e.g.;, until the,date 
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a concert actually takes place? " • 
Claims V : : 

1. Anirrtegi^^droirtcard(l)^ 5 
means storing sendee data relating to at least one 
service, chWacterisedin that at' least part of said 
memory means comprises service data in file struc- 
tures within one directory comprising a first file and 

a second file, service data being grouped together - 10 
th'sen/ice slots* any service slot being divided into a 
profile 1 part and a data part, any profile part having- 
a slot number (RN(i)), and being stored* in said first 
file and comprising a unique application identifier 
and any data part being stored in said second file is 
and comprising data relating- to the service;-said 
memory means storing at least one key r '(Ks2) to 
protect write access to said first arid r secdnd;f iles. • 
" - ' • r • : -" v; * t * ,< •* \t~l\i *r v-\i 

2. An integrated circuit card (1) according to 'claim .1, 20 
characterised in that -at least one profile' part also 
comprises data relating to an expiry date - of the 
service slot concerned. * v 

» ^ Mi.v • *: * *v. • -*n = r , -..c . . \\i v;:?? • : 

3. 1 Ah integrated circuit card (1 ) according to claims or 25 
2.' characterised in that at least one profile part- also 
comprises data relating to an application status; ■*» 

4. 'An integrated'eircuit card (1) according to any of the 
preceding claims, characterised in that any service 30 
slot comprises its owvh profile part and its own-data 
part, any profile part being implemented as a record 

of said first file and any data part being imple- 
mented as'a record of said second file, said mem- 
ory means storing a further key (Ksl)' to protect 3S 

access to said fir^t file. 

5. An integrated circuit card (1) according to any of the 
claims 1 or 2 or 3, characterised in that the imple- 
mented* service slots share one common profile 40 

< part but any service slot comprises its own data 
part, said common profile part being implemented 
as one record of said -first file and the data parts 
being implemented as separate records of said 
second file. l - 45 

6. An integrated circuit card (1 ) according to any of the 
preceding claims, characterised in that 'said direc- 
tory also comprises a third file and at least one 
service slot comprises an additional date's panVin so 
said third file for storing additional data. 

7. fc An integrated circuit card (1) according to .claim 6. ~ 

\ characterised Mn that said at least: one -additional, : 
data part is implemented as record/ ^.-./.V.^:. .55. 

* \-- V r* ; l>, ■? „ ^Yi-ji ^.v * * . r 

8. ' A r sebure application module (3Vequipped:to corn* <; 
• s munlcatewith an integrated drcuit-c^tacrording*^ 



to any of the claims 1 through 7, provided with 
memory means storing service data relating to at 
least one service, characterised in that at least part 
of said memory means comprises service date in 
ffle structures within one directory, said directory 
comprising at least one file,, said at least one file 
storing service data relating to. one single service 
grouped together into: . - ; 

application/service definition data comprising a 
unique service identifier and data indicating a 
service type; * * -y : T 

- * at least, two application counters, for adminis- 

trating.the number of allocations and for gener- 
ating a unique record transaction number; - - 

- a i service sequence- counter for generating a 
^unique object number and administrating : tjie 

number of created service objects; ■ - . . 
a service float for administrating the number of 
either issued or received value units and 

- data relating to accessirights (A),defining.sery- 

; ice actions ^allowed to be performed by pred^ , ^ . 
. . fined terminals (2),, . ^ . - . 4 i 

and in that said memory means- com- 
prises at least a first key (Ks2) and a second :J 
key (Ksam) for protecting any date communicar . . 
tion with an integrated circuit card. . - r: - 

9. A secure, application module, according to claim 8 •,. . 
wherein said memory means store a third -key (Ks-l).,-.-. j r 
rfbr protecting-:any date communication with an inte- >- 

-grated -circuits . v • .r:-v - 1:.-- m ::/?«; ..- >: v 

10. A system comprising a secure application module v r/., 
(3) according to claim 8 or 9 andat -least onetejrmi- ^ »* t $d 
:nal (2) coupled to^said secure application module,;, ;; - :V: 
said terminal (2) being equipped to . communicate \ < , 

with .said ^secure, application module and with , at 
least one^integrated circuit (1) according to any of : . 
theclainre 1 through 7 in order to.contrpl a . service: , 
action carried out on said at least one integrated dr- - 
cuitcard. : ~. . 

11. Method for controlling a service action.tqbe carried . 
-out by a terminal (2) on an integrated circuitcard (1 ) 

according to any of the claims 1. through 7, said ter- 
minal (2) being coupled to both a secure application - , 
module (3) according to any of the claims 8 or 9 and - 
to said integrated circuitcard including theW-. 
lowing steps: ' , * a : ; . 

^ ;a.. establishing whether said ,temriinal (2) ,1s, 
allowed to carry out said service action orvsaid , 
integrated service card (1 ) by using at least one 

, , . code (C, S) and at least one secret key (Ks2) , : 
both said at least one code (C, S) and said, at . ; 

v > least one tey (Ks2)« being stored, on berth said 
. .integrated , circuit y card ^ :(1):;andj said secure! . * 
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application module (3) and by checking prede- 
termined access rights (A), and 

b. carrying out said service action on said inte- 
grated service card (1); 

c. checking step b. on said terminal (2), s 
characterised in that : 

said checking predetermined access 
rights (A) in step a (steps of lines 831-836) is 
carried out on said secure application module 
(3) using said data relating to access righis (A) w 
stored on said secure application module (3) 
and said at least one code (C, S). ; 

12. Method according to claim 1 1 , characterised by the 
following step prior to the step of checking predeter- is 
mined access rights (A) in step a: reading out serv- 
ice data (D) from the service slot and storing in said 
secure application module (3) a predetermined 
data part (D.fixed) of said data (D) which has to 
remain unchanged; and by the step of carrying out! 20 
step b. without changing said predetermined part 
(D.fixed) of said data (D) on said integrated circuit : ; 
card(1). - ^ 

1 3. Method according to claim 1 1 or 1 2 characterised in 25 
that the service action includes securely reading 
out from the integrated circuit card which includes 
the following sub-steps: 

reading out an integrated circuit card ID; 30 
selecting the service slot associated with the 
integrated circuit card ID; 
reading and verifying at least service slot data 
and service slot definition; 

storing a stamped MAC and random number of 35 
the service slot definition and the service slot 
data; 

securely storing the integrated circuit card ID, 
service slot definition and service slot in a third 
party memory; 40 
erasing service slot and releasing service slot . 
definition. 



erasing the third party memory. 

15. Method according to claim 11 or 12 characterised 
by temporarily locking a service slot on the inte- 
grated circuit card. 



14. Method according to claim 13 characterised in that 
the service action includes the following steps after 4s 
the method steps of claim 13: 

verifying whether the data in the third party 
memory was read out from the integrated cir- 
cuit card by checking whether the stored inte- so 
grated circuit card ID equals the integrated 
circuit card ID; 

selecting a free service slot in the integrated 
circuit card; - 
allocating a free service slot with a service slot ss 
definition in the integrated circuit card; 
writing service slot data in the selected free 
service slot, and 
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825„ select correct file . _ 

626 get request <- ASK RND2 
827. generate, RND2 

828 store RND2 • e, . .., /, 
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